我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

前面幾篇整理 ERP 導入時，我一路從需求訪談、流程決策，談到人工判斷與系統應該承接多少。這些討論最後都會碰到同一個問題：即使流程已經談過、Decision 也做完，還是不能只因為會議裡大家都點頭，就認為這套做法可以直接成立。

有一次在採購流程的討論裡，ERP 顧問介紹系統可以直接從需求產生採購單，不需要先經過請購。導入方當下很明確地說，公司採購一定要先走請購，而且請購還需要經過一層審核，因此直接轉採購的功能甚至可以鎖掉。這段討論當下沒有太多模糊空間，看起來已經是一條可以直接做進系統的規則。

但後續會議裡，又出現某些 C 類需求如果前面已經審核過，就可以直接進到採購，不需要再多走一次請購的說法。從目前逐字稿，我無法確認兩次討論是不是完全相同的情境，也無法判斷最後正式採用哪一個版本，但這種情況在導入現場很常見。第一次討論時，使用者可能描述的是一般流程；到了下一次會議，才因為談到特定品項、角色或例外，補上新的條件。

這和前面談需求訪談時的情況很接近。使用者說「我們都是這樣做」時，不但要當成一個適用範圍仍待確認的描述，還必須再放回真實工作情境確認一次。因為人在會議裡討論的是一套抽象流程，真正工作時面對的是一張有客戶、有品項、有數量、有庫存，也可能帶著例外的單據。

流程在會議裡說得通，實際操作時才會看到缺掉的條件

流程訪談很容易得到一些看起來很完整的答案。請購之後走採購、替代料由生管判斷、某個欄位由某個角色負責，這些都可以直接畫進流程圖，也很容易在會議紀錄裡留下結論。

但只要真的讓使用者操作，問題就會變得具體很多。這張單應該從哪裡開始、這個欄位在這個時間點到底有沒有資料、下一個部門看不看得到前一個人留下的資訊、遇到特殊品項時是不是還能走原本那條流程，這些事情在討論階段往往不會一次全部出現。

如果使用者真的操作之後發現流程走不下去，原因未必是程式有 Bug，也可能是前面的流程少問了一個條件、兩個部門對同一個流程的理解不同，或原本打算交給系統的規則根本沒有想像中穩定。這些問題如果一直停留在流程圖與會議紀錄裡，很容易被誤認為已經確認完成。

我比較傾向在很小的範圍內，提早讓使用者碰到系統

也因為這樣，範圍還很小的時候，只挑一段流程、一種訂單或幾個實際案例，最好就讓使用者正式操作，比較容易確認目前對流程的理解是否正確。

如果等到整個功能都完成，甚至已經進入正式 UAT，使用者很容易把測試理解成「系統已經做好，現在只剩確認能不能用」。這時候如果發現流程方向有問題，修改的不只是畫面或欄位，可能連前面的流程、權限與資料設計都要一起回頭。

小範圍測試對我來說主要是在降低這種成本。當錯誤只影響一小段流程，大家比較容易接受重新討論；如果驗證結果和原本預期不同，也還沒有大規模影響營運。Pilot 降低的不只是上線風險，也降低前面決策做錯之後重新修正的代價。

而且一旦把實際單據放進系統，很多原本很難在會議裡想像的問題會自然跑出來。使用者可能會發現某個資訊在那個時間點根本還拿不到，某個角色其實不會看到這個畫面，或一個原本覺得合理的操作每天做二十次之後變得非常麻煩。這些回饋通常比再多開一次流程確認會議更具體。

測試對象本身，也會影響你看到什麼

那要找「誰」來測試，是要很小心的決定。主管通常對部門責任、流程與管理需求最清楚，但也通常最忙，很難每次系統有一點調整就配合測試。第一線使用者最熟悉日常操作，不過每個人對改變的接受程度差很多。有些人願意一起討論新流程，也有些人平常對公司、系統或工作方式就已經累積很多不滿，一進到測試現場，很容易把這些問題一起帶進來。

我比較常找的是部門裡接近「二把手」的人。這不一定有正式職稱，比較接近主管正在培養、部門裡也知道未來會承擔更多責任的人。這類使用者通常已經足夠熟悉實際流程，又不像主管那麼難安排時間；因為本來就被期待承接更多事情，對跨部門合作、新系統或流程調整的積極度通常也比較高。

這種選擇當然不能取代正式 UAT，也不能代表其他使用者都會有相同反應，但在系統還需要快速修正的早期，先找到一個既懂流程、又願意合作的人，會比較容易把真正的問題辨識出來。

說明文件和操作錄影有用，但測試最好還是當場發生

我通常會在測試前先準備一封功能說明 Email，把這次改了什麼、希望使用者測哪些情境，以及有哪些地方需要特別留意寫清楚。如果操作步驟比較多，也會另外錄一段實際操作影片，讓對方先知道整個流程怎麼走。這些素材可以降低第一次使用的門檻，也省掉很多重複教學，同時向客戶傳達開發的進度。

但是，營運人員每天都有原本的工作，系統測試很常沒被放在心上。Email 看過了、影片也收到了，過幾天工作一忙，很容易就把這件事往後放。如果這次測試會直接影響下一步開發，我現在更常直接約一場線上或實體會議，請使用者當場操作。

而且測試時我會盡量不要一路教他怎麼做。使用者第一次打開系統後會去哪裡找功能、怎麼理解欄位、在哪一個地方停下來，這些行為本身就是很重要的資訊。如果每一步都有人在旁邊提醒，很容易測到的是「有人教的情況下功能能不能完成」，而不是這套流程本身是否足夠清楚。

使用者真的開始操作之後，新的需求通常也會一起出現

實際測試很少只有通過或不通過。使用者一開始操作，很快就會提出新的想法，例如希望多一個欄位、少一個步驟、順便把其他資料帶進來，或者針對某個特殊情況增加另一條流程。

這些回饋裡有些確實代表前面漏掉的重要需求，也有些只是個人的操作習慣，或一年只會發生幾次的特殊情境。如果每個 request 都直接接受，系統很快又會長出大量例外；如果全部用「不在 Scope」擋掉，使用者也很容易覺得測試只是形式，自己提出的問題沒有被真正理解。

這裡我覺得很依賴溝通的手感。除了判斷功能本身值不值得做，也需要考慮這個需求不處理會不會影響後面的合作與 adoption。有些需求可以清楚說明為什麼目前不做，有些先記進 backlog 就足夠；也有少數功能本身價值沒有特別高，但如果剛好解掉一個關鍵使用者每天都會遇到的摩擦，投入一點成本可能會讓後續導入順利很多。

所以測試過程裡實際被驗證的，除了功能是否正常，還包括流程是否符合工作方式，以及使用者願不願意真的採用。

Verify 會驗證所有的假設是否正確

如果把這裡的思考放回我目前整理的五層 FDE 工作框架，Verify 在做的，是實際驗證前面提到的 Observe、Clarify、Decide、Encode 是否成立。

這個邏輯和 MVP 也蠻像的，範圍越小、時間越早，越容易讓錯誤的假設被修正。找一個適合的使用者，挑一段足夠小的流程，準備基本說明，再直接讓他自己操作一次，很多原本只能靠會議推論的問題就會變得很具體。

Verify 完成之後，也不代表流程就一定往下一步走。有時候會重新回到 Clarify，因為新的例外被看到；有時候回到 Decide，因為兩個部門原本以為已經有共識，真正操作之後才發現理解不同；也可能回到 Encode，重新調整哪些事情需要系統限制，哪些可以保留人工彈性。

會議裡把流程講清楚很重要，但還是使用者自己打開系統，用一個接近真實工作的案例測試，才能確定真的是解決使用者的問題。

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！